home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group98a.txt / 000078_icon-group-sender _Mon Mar 2 16:43:54 1998.msg < prev    next >
Internet Message Format  |  2000-09-20  |  3KB
  1. Return-Path: <icon-group-sender>
  2. Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
  3.     by baskerville.CS.Arizona.EDU (8.8.7/8.8.7) with SMTP id QAA01604
  4.     for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Mon, 2 Mar 1998 16:43:54 -0700 (MST)
  5. Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
  6.     id AA03745; Mon, 2 Mar 1998 16:43:52 -0700
  7. From: gep2@computek.net
  8. Date: Sat, 28 Feb 1998 02:42:55 -0600
  9. Message-Id: <199802280842.CAA09087@axp.cmpu.net>
  10. Mime-Version: 1.0
  11. Content-Type: text/plain
  12. Content-Transfer-Encoding: 7bit
  13. Subject: Re: icon questions
  14. To: icon-group@optima.CS.Arizona.EDU
  15. X-Mailer: SPRY Mail Version: 04.00.06.17
  16. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  17. Status: RO
  18. Content-Length: 1968
  19.  
  20. > As one who manages programmers, I heartly agree that programmer time is 
  21. what really costs you. 
  22.  
  23. Absolutely.  It came as rather a shock to one client (and this was already about 
  24. 4 years ago) when I pointed out that ONE EXTRA DAY of programmer time (debugging 
  25. a more complicated TSR they thought they wanted) would cost them almost as much 
  26. as a second computer, which kept the system and programming simpler.
  27.  
  28. > Not only are programmers expensive, it so happens 
  29. that if they are wasted doing something useless, they are not programming 
  30. the next project you have for them.
  31.  
  32. Absolutely.  The biggest problem with most of the programs you need is that you 
  33. don't have them!!!!  And don't have time to write enough of them, using 
  34. traditional programming techniques.
  35.  
  36. > However, this is no reason to produce sloppy code... In the majority of 
  37. the cases I see of sloppy/slow/unelegant code, the reason isn't that the 
  38. solution was really cheaper in man-hours. It means simply that the man is 
  39. not a great programmer.
  40.  
  41. Agreed that "good" programmers are usually a good investment.
  42.  
  43. But the fact remains that it takes more time to write tight, efficient code, and 
  44. many companies really don't want to pay what that time costs.  Whether by a good 
  45. programmer, or even a bad one.
  46.  
  47. > In some cases (for example onetime scripts, higly clever algorithms etc.) 
  48. dealling with all the low level stuff (such as type conversions) is a 
  49. waste of time. 
  50.  
  51. Right.
  52.  
  53. > But even in such cases, the compiler should be able to optimize most of 
  54. the trivial performence problems. Unnneded (obvious) conversions are an 
  55. example. 
  56.  
  57. > The sad thing about optimization, is that it is never a replacement for a 
  58. good programmer, and a good algotrithm. 
  59.  
  60. I highly optimized BAD algorithm will usually be nowhere near as fast as a 
  61. REALLY SLOPPY-IMPLEMENTED good algorithm.
  62.  
  63. Gordon Peterson
  64. http://www.computek.net/public/gep2/
  65. Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
  66.  
  67.